x86/hvm: further restrict access to x2apic MSRs
authorAndrew Cooper <andrew.cooper3@citrix.com>
Tue, 21 Oct 2014 15:34:20 +0000 (17:34 +0200)
committerJan Beulich <jbeulich@suse.com>
Tue, 21 Oct 2014 15:34:20 +0000 (17:34 +0200)
commit8d0a20587e4ebf3691ee88a55f91f398c4d2ee83
treea7bb3f29f063d3651b1f67f58b1b3587690958ae
parent2be76df6c4e61904b6c107f089fd7195dac1d5cc
x86/hvm: further restrict access to x2apic MSRs

The x2apic specification reserves the entire MSR range 0x800-0xbff, while only
the first 0x3f MSRs have defined purposes.  All reserved MSRs in this region
are architecturally required to raise #GP faults upon access.

Xen used to pass this entire range to hvm_x2apic_msr_{read,write}(), but the
range was restricted somewhat by XSA-108 (c/s 61fdda7ac) to prevent guests
being able to read pages adjacent to the domheap page backing the vlapic->regs
array.

While removing the vulnerability, a side effect of XSA-108 was that the MSR
range 0x900-0xbff fell through the switch statement and ends up reading the
hosts x2apic range. This behaviour is a problem in general, but specifically
it turns out that MSRs 0xa00-0xa02 are implemented (but undocumented) on
certain SandyBridge and IvyBridge systems.

Experimentally, no operating system in XenServer's test suite (including all
versions of Windows currently supported by Microsoft) ever peek at these MSRs,
even on hosts where some of them are implemented.

This patch undoes the fix for XSA-108 (c/s 61fdda7ac), returning the primary
bounds check to the entire specified range.  hvm_x2apic_msr_write() was always
safe, as it is whitelist based.  hvm_x2apic_msr_read() changes to a whitelist
approach, which avoids the vulnerability, and provides a more architecturally
accurate emulation of the reserved MSRs (which would previously read as 0
rather than fault).

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
xen/arch/x86/hvm/hvm.c
xen/arch/x86/hvm/vlapic.c